It is important that the test manager informs the participants correctly about the idea of a PRA and what is expected of them. He can do this by talking to each participant, by sending them an explanatory text, or by organising a joint kick-off beforehand. In such a session, the test manager summarises the PRA, the test strategy, the vision of testing and the upcoming test process, and allows the participants to ask questions. The test manager should avoid test jargon. The participants’ familiarity with PRA is the main determinant in the selection of a method. The test manager also asks the participants to prepare for the session or interviews. Some do not need to prepare and find it easy to specify the risks; others may find it useful to think about the risks that are relevant to them in advance. The system documentation and (existing and new) business and management processes are important input, both for obtaining the test goals and for distinguishing the characteristics and object parts.

The participants then receive an invitation to the session or interview. Naturally the test manager organises (or orders) the required logistical facilities in advance. The test manager prepares by familiarising himself with the concepts used in the organisation, both business and IT. He must make sure that the risk of confusion in relation to terminology and concepts is as small as possible by allowing the participants to speak their own language as much as possible. Many test managers create a first draft of the PRA for themselves during preparation, ensuring that they are well prepared and able to get the real PRA moving or moving on if needed. Still, we recommend keeping such a first draft as a backup to avoid giving the impression that the test manager is manipulating the PRA result or has determined it in advance.

Indirect PRA input

In addition to direct input for the PRA, such as the test basis, business and management processes, there are also various information sources representing indirect input for the PRA:

• Assignment formulation - The assignment formulation specifies the aim and scope of testing, providing important indications to what the client believes is important. It also contains the planned test levels for the MTP.
• Project proposal and business case - Such documents often contain the reasons why a system or package must be developed, implemented or adapted and sometimes even provide risk indications at a high level.
• Business requirements - Requirements can be split up into business, user and system requirements. Requirements have a priority marker. This does not say much about the associated risk – at most it says something about the potential damage, and even this can be subject to discussion. Business requirements with business objectives like X% faster, cheaper and/or more turnover can, at most, be used as background information in the PRA or test strategy. User requirements and system requirements are types of test basis and therefore constitute direct input for the PRA.
• Project risk analysis - Often such an analysis contains primarily project risks instead of product risks. Moreover there is a good chance that the risks have already been covered by other counter-measures when the PRA starts, reducing the height of the product risk. When this is taken into account, the project risk analysis constitutes a useful source of information for the PRA.
• Business risks - Business risk are the risks that play at the highest organisation level, such as the failure to take a new product to market in time, a successful product from a competitor, or disappointing sales figures. These risks can help provide background information for the PRA, but do not represent direct input. Testers are usually not at the right level in the organisation to be able to talk about business risks. Also, the risks are often not documented or at least not part of the test basis. Still, this knowledge is very valuable to make a good risk assessment of the system. Message: Find out about this to get a better understanding of the system. When the business risks are known to the PRA participants, this does not mean that the test manager must communicate and report at this level. That depends entirely on the client level and test goals.